从ITIL到SRE | 唯品会运维自动化实践

作者简介

王喜春

唯品会 高级运维开发经理

毕业于中国人民大学，有着近十年的运维开发经验，先后在YY，唯品会工作，现任唯品会高级运维开发经理一职，负责整个运维体系的建设，在监控，持续集成和自动化运维方面有较深的理解

前言

今天给大家分享的题目是“从ITIL走向SRE”。 ITIL 和 DevOps 两种体系只是一种方法论的差别，没有好坏。

今天这个题目可能让大家有一些误解，并不是说SRE 就要比 ITIL 好或者 ITIL 比 SRE 差，只不过是在不同时代的产物，相当于我们每个人都会走向成熟，大家都会从童年走向青年、走向老年，我们都会迈向老年的阶段，但是不能说童年和青年没有价值或者童年和青年要比老年强。

我会从以下四个方面阐述我的整个演讲：

一，ITIL，建设方法及瓶颈

二，困境，破局

三，自动化，SRE尝试

四，个人心得和感悟

一、ITIL，建设方法及瓶颈

唯品会整个运维体系的建设是从2013年开始，实际上唯品会这家公司是在2008年成立的，到2013年经历了五年时间才开始发展运维，这是一个业界很正常的现象。因为运维往往都是走在开发后，业务先要保证能活下去，活下去之后才能找一些人去做运维工作。

2013年唯品会的单日订单量达到13万，会员数量达到5000万，服务器大概8000多，应用服务130多个。在这种情况下，全年的有效报障数是5700多个，相当于一天大概有将近20个报障。这里5700是估算，相信实际数字比这个多。我是2013年加入的唯品会，我面临的就是这样的场景，怎么把故障量降下来。

1.1 运维能给公司带来什么价值

作为运维人员，我们一直谈运维能给公司带来什么价值。

很多人总结说我们有四点：质量、安全、效率、成本，这些我都赞同。不过大家记住，质量是及格项，当我们质量 hold 不住的时候，上面那些再高也没用。

提升质量，当时的想法很简单，如何能把质量稳定下来，无外乎两点。

第一点，怎么样做一些线上操作时不会发生故障；

第二点，当发生故障的时候，怎么能快速把它解决掉。

这两点合在一起其实再说一件事，要可控，遇到故障我能不能控制住，那么，要怎么样做到可控。

1.2 建立ITIL体系系统做到可控

能不能上一些流程，有了这些流程，我规范一下行为，让他在做一些东西的时候，一层审批，如果不行就两层审批，两层不行就三层审批，层层让这个事情变成可控。基于这个，我们2013年建立了 ITIL 体系。

首先它是全面围绕流程为核心，在质量效率发生冲突的时候，2013年我们选择保质量。所以我们开始建立各种流程，包括发布流程、变更流程、故障处理流程，问题管理流程。

唯品会在当年流程优化做到很精细程度，整个发布要走3-5天。从开发要写代码的时候，最终达到线上给用户交互的时候，需要近一周时间用户才能看到。一个变更流程要走2-3天，我们要求开发提前24小时提变更单，中间要经过经理审批，有的时候还需要总监审批，质量可控后才可以做变更。因为有了这些流程，才有了后来搭建各种系统。

在整个 ITIL 大家会看到这样的现象，一定先有流程再有系统，整个系统是为流程服务的，如果没有流程，大家在建设系统的时候都比较空谈。在ITIL阶段，实际上也不太关心有没有系统，假如说没有发布系统怎么办？你手动去做，或者用开源系统搭建，只要能体现流程就可以。

1.3 做好ITIL的四个方面特征

ITIL 体系有这四个方面特征，大家怎么做好 ITIL 要做的事情，我给大家逐一解释一下。

第一，它一定是一套管理体系，这个跟大家理解的 DevOps 或者SRE都不太一样。它是管理思想落地，既然是管理思想，整个 ITIL 一定是运维主导，因为整个过程都是他建立的流程。什么叫管理，管理的思想在某种程度上要用一套制度呈现出来，落到纸面上就是一些流程。

第二，先有流程，后有系统，流程推动系统迭代。

第三，故障发生后，想的办法就是修改流程或者增加制度。比如一个容量评估发现不够了，如果按照 ITIL 体系怎么做，大家想的是不是我在哪个流程环节出问题了，流程上有没有优化的空间。能不能更快的发现问题，这个不是整个 ITIL 关心的，它关心的是不是容量发生故障之前就发现它，然后是扩容或者缩容。

第四，责任到人而非系统。

1.4 案例解析

案例一、发布流程

下面给大家举一个例子，这个是唯品会目前的发布流程。

整个发布流程是从研发开始，中间到测试，再到 TC，然后由运维把它部署到线上。做了这个流程之后才开始做一些系统的开发，比如说在这里我发现需要编译系统，那我可以找开源的 Jenkins ；这里我发现我的代码包需要把它扔到一个地方，让其他服务来取；这里我发现在线上部署，开始搭建各种云之类的，在这里我做一个 PLCS ，线上审核，审核之后在线上发布。

这里会碰到一个问题，比如我每周或者每天有很多个服务或者很多个应用要发布，我整个发布过程中，这些服务一定是有先后顺序的。我先发哪个服务，先发哪个应用，后发哪个应用，哪些应用之间有前置依赖，哪些一定要同时上生产的。

在这种情况下如果用 DevOps 思想，他可能会自己制作一个策略，通过策略来解决，但是在 ITIL 体系，它一定是通过流程来解决。

在唯品会要做的事情就是，又建立一个新的流程，这个流程是在2015年到2016年建立起来的，被称为是一个火车发布模型。

在这里每个要做的事情，大家可以这样理解，既然叫火车发布，它就跟火车相关。比如我要坐火车去哈尔滨，首先我要买票，记下来要选择一些车次，看一下哪些车次我能到哈尔滨，然后我在上面抢座位，买好之后接下来等火车开，整个火车有列车长，这个列车长获得整个火车在运行途中的行程安全。

火车发布也是这样的，我们每周一会把这些应用做一个排序，这些应用相当于我要挤哪列火车。到周三周四上线之前，把所有的排好，接下来做的事情是按照正常来。

但是有一些应用很急，比如线上修复代码bug，整个火车票有限，容量有限，这时候火车长可以去调整座位，他觉得你比较急或者你的总监审批了，就可以把你的往前调或者往后调，整个过程是模拟火车发布。

当我遇到一个新问题的时候，实际上又有了一个流程，比如在 ITIL 体系我想删减一个流程，最后发现又多了一个流程。

这样做的好处是，质量一定是可控的，比如我变更，假如说我一天变更量有100个，现在我给你上变更流程，我把流程拖长了，拖长之后这个变更要走三天，接下来会面临什么问题，每天的变更量是30个，照原来的相比，我的质量一定可控，这就是整个 ITIL 在唯品会给它带来的最大价值就是质量可控。

案例二、全网巡检

第二个例子，刚才所说的整个流程，我们每天会发一个全网的巡检，检查全网正不正常，网络正不正常，服务正不正常。

这些东西人是画不出来的，我每天让他保证一个小时就巡检一次，这时候怎么办？系统把这些都画出来了，系统来判断，有一些指标，这些指标给他之后确定这个正不正常。现在带来一个问题，谁来发这个报告，系统把所有的数据、所有的报表都帮你准备好了，接下来你要做的事情就是点一个发送按钮，把这个东西发给公司各个层面。

这个报告既然是系统来做，系统一定能做到自动取发，大家一定要相信这个事实，人能做到的事情系统都会帮你做。这时候我们碰到一个问题，谁会发这个报告。

这个就是举的例子帮大家理解一下，整个 ITIL 最终的责任一定落在人的身上，不是落在系统身上。

在唯品会这个报告一定是由一个人来发，不管这个人是什么级别，他每天定时发这个报告，他很辛苦很麻烦，每天什么事不做，就点按钮。但这样做有什么好处，有问题我能找到这个人。

如果有问题能找这个系统吗，这个系统会面临很多个，包括开发、测试、监控，很多人，一个系统有问题，根本找不到责任人。在整个 ITIL 体系，我一个系统最终落地就是责任到人，由这个人推动系统的优化，所以这个报告现在还是由人来发，在没有新的方式或者新的企业文化建立之前还是按这种方式来做。

二、困境、破局

我们整个 ITIL 大概经过了三年时间磨合，从2013年5月份一直到2016年年初，然后在这种情况下，我们看一下整个 ITIL 取得的成绩。在业务上，原来是13万，现在到百万级别，会员数开始翻倍，节点都开始翻倍，带来的好消息是故障量降低了，全年大概是2800多个，包括了重大故障和非重大故障， ITIL 取得的成效是非常显著的。

既然 ITIL 这么好，我们能不能一直用下去？任何一种思想，在没有新的思想取代 DevOps 之前，一定也会面临这种问题。任何一种思想都会有利有弊，有好的有坏的，只不过是你看重哪一个。比如我看重质量就可以用这个，看重效率就可以用那个。

2.1 ITIL的困境

2016年碰到一个什么问题，这里给大家举一个故障，其实不是个特别大的故障，全网抖动。网络发生抖动了会不会影响业务，这个故障我描述一下。

大概是去年发生一次网络抖动，由于它抖动的不是我们的核心机房，以前也经常发生，不是一个个例，经常发生，又是发生在凌晨大概1点钟这样，网络那边收到报警，没有当回事，放过了，第二天早晨发现影响业务了。这个业务的量本来不大，但是随着时间的累积，把这个故障变大了。

接下来我们面临一个问题，网络应不应该告警，或者说网络的告警级别要不要调，因为不同的告警级别对应的是不同人员的处理时效，如果把严重级别调整为灾难级别，不管什么时候，半个小时内上线把这个处理完。故障其实挺简单，网络发生告警，监控人员没把它当回事。

第二天发生故障了，面临一个问题，要不要调整告警级别，如果按照 ITIL 思想一定是调，因为出问题了，解决单点就可以了，把告警调整成灾难。但是过不久，由于这不是个例，会经常发生，人会不会疲惫，会不会忽视，之后会不会再把级别往下降。2016年之后我们一直在思考这个问题，怎么把 ITIL 这个怪圈跳出来。

整个 ITIL 会碰到这四个方面的问题：

第一个是流程效益问题，原来一个变更，把故障降下来。接下来再增加一个流程所带来的边际效益会越来越低，这是个经济学的问题。比如我有一块地，原来我纯手工做操作，一定效率很低，可能我一个月才能把庄稼种完。

现在我有钱了，买了台拖拉机，提升的效率会非常高，接下来我可能在三天就可以把一个月的活干完。如果再买了台拖拉机，能帮我节省27天时间吗？这就是所谓的边际效益随着流程增加会越来越降低，如果画条曲线可能是这样的，接下来慢慢变平，而对效益影响是越来越低的。

第二个是人的问题，任何一个企业中包括我们运维也好，最难管理的一个问题就是人，怎么管理人？我一直说每种体系无论 ITIL 也好，或者 DevOps 亦或者SRE这种思想，本质来说就是对人性的一些管理。人是有情感的，虽然流程增加，他会越来越腻烦，腻烦到一定程度之后他就会存在侥幸心理，我不用你的流程。我所增加一个流程要考虑他们的感受，他的感受是好还是坏。

第三个是流程无法穷尽，不光网络，还有很多故障无法穷尽。但是在公司层面关心的是，不完全是你避免了哪些故障，更主要看新发生哪些故障没有有效控制，这也是运维人的一个悲哀。

第四个是流程的波动效应，我虽然只改了一个监控等级，接下来我会面临什么问题？比如今天我发现这个告警是有效的，我要提升灾难了，在过去365天，有364天这个告警都是无效的，我调整这个是不是否定去年364天的正确性。

2.2 谁应该为服务的个性负责：自动化和SRE

再举个例子，这个告警级别应该由谁来负责？如果我们重复刚才的行为，磁盘空间满了，造成重大故障，按 ITIL 或者按公司原来的企业文化会怎么做？我会调整级别，但这种一刀切的做法对其他服务公平吗？如果这个服务对磁盘是高依赖的，有一点抖动都会带来很严重的问题，我调整是有效的。

如果这个服务不高依赖，而且我写得很慢，我告警阈值是80%，现在你要求我马上处理，对我公平吗？

这块就面临一个问题，同样道理，我这里举的磁盘空间，任何一种告警任何一个服务都需要有一个人来确认，我需要哪些告警，这些告警应该是什么级别，或者说有没有一个人能出来帮我敲定，说这个服务出现，只要你监控这些东西，或者投入这些东西来处理，就足够了。

这是在2016年我们碰到一个问题。接下来我们开始做自动化和SRE尝试。

三、自动化，SRE尝试

坦率来说，唯品会的SRE还是属于比低级的阶段，处于一个探索起步的阶段，我觉得最困难的是在探索阶段。所有都有可能，你怎么做都是对的，但是怎么做又都可能是不对的。

经过一年左右探索，在生产上30多个服务做这种尝试，全网有2300多个，为了稳妥，我们30多个在尝试，整个在摸索在尝试，我接下来给大家汇报在这一年中我们尝试做了哪些事情，哪些值得跟大家分享。

3.1 唯品会定义的两个运维职责

整个SRE在唯品会把它定义两个职责：

整个SRE在唯品会把它定义两个职责：

第一个是把你的运维能力转移出去，它要做的事情是你原来运维做的事能不能让其他人做，比如服务台能不能做，开发能不能做，测试能不能做。

第二个职责，他要对服务质量负责，也是责任归属的问题。对生产的任何问题，给了你足够多的权力，你可以对服务应用上线说no，你要承担相应义务，出问题你要负责和改进。

接下来会分别阐述一下这两个职责他们做了哪些事情。

3.2 运维能力前置-系统架构

首先是运维能力前置，他们做了这两个，第一个是开发系统，我们SRE由两部分人员组成，我带工具开发团队，所以他们是承担主力的，大概70%的人来自于这个部门。

接下来我们会把移动运维一部分也补充过来，要求移动运维团队的情况是有开发系统能力，能把自己琐碎的工作做出来。

这是他当年给我规划的整体的架构设计图。问大家一个问题，当我们真的把运维效率提升了，比如你原来8个小时工作，现在变成4个小时文成了，另外4个小时做什么？如果我有一个部门10个人能完成的东西，我现在5个人能完成了，另外5个人干吗？如果不寻求改变，就会出现人力资源过剩。

3.3 运维能力前置-jarnitors

接下来是让另外5个人做什么，要做什么业务引擎、可视化图形报，要从线上的运维转到线上技术运营。

这个系统是他们做整个运维能力迁移的最重要的系统，全称叫自动化运维平台。整个系统提供两种能力，第一种是解决人和服务器之间的关系，我要求任何人在限定的情况下允许把某些命令直接下发到服务器上。

我在任何机器间做了一层隔离，这就是这个系统要做的事情，任何人都可以操作生产，操作生产要走一些审核。干的第二件事是走第二条通道，一个是下行的，把命令往下发，一个是上行的，要求能把生产中的所有的数据上报上来。

这样做的好处是降低了一些人的开发成本，我们运维最困扰的就是架构能力，坦率来说，我对运维想搞一些大数据那些东西实际上是抱有一些怀疑态度，可能现在理解比较肤浅，我总觉得这些东西要交给开发或者交给其他现成的大数据部门帮我们搭建，我们要做的事情就是你把数据报上来，报上来之后在那边能取就可以了。

上边的任何数据都可以调底下的接口，我写到消息队列里，其他人读就可以了。接下来做了一些工具的开发，我们在这里封装了各种脚本命令，像这种RPM包，类似这样我们是固化在代码里的，不允许别人修改的，保证任何人在线上都可以操作，保证这种操作是可重现的，接下来运维人员慢慢解放出来。

3.4 运维能力前置-自动化

另外是做标准化，我们原来所有东西，大家没有想法怎么做事情，如果每个团队都可以自己去做，遇到一个什么问题，大家都可以自己敲定，做完之后谁好谁坏谁说了算，没人知道。这个团队说我做得好，那个团队说我做得好，最后都不标准。做完标准模板之后，通过命令下发模式，接下来再做自动化变更。

3.5 如何对质量负责？

再者对质量负责，我们提了这几项要求：

第一，所有SRE人员都要能读懂代码。这个很难，现在大概有一两个能读懂开发代码就不错了，绝大多数人都不大读懂。我们为什么要读懂开发代码，整个开发人员是对业务进度负责的。实际上在业务开发进度很紧，有很多项目经理在催促他们，让他们定时上线、按时完成，所以他写的代码很多情况下是不会再考虑一些异常的。

这时就需要SRE能看懂代码，他知道在哪加监控，哪块异常。要求他们能自己改代码，业务代码不用改，但是异常能不能知道，异常之后你能不能写一些代码做补充？

第二，他要对整个服务的监控负责，监控代表什么东西，我刚才所提的概念，当一个服务发生之后，我究竟要监控哪些项，怎么设置阈值，设置哪些告警级别是合理的，这些都要由SRE人员把控。

第三，是开始优化流程，现在流程已经达到一个瓶颈。整个 ITIL 是一个管理体系的落地，有些流程是必须必要的，但有些流程可以优化，优化的思路有两种，能用系统代替就用系统代替，不能用系统代替的怎么减少环节。

3.6 对于SRE实施上的总结

这就是整个部门对SRE做的一些要求，因为在探索阶段，所以真正能给大家做分享的不是特别多，这只是我们目前已经做的一些东西。

但是我相信接下来，比如再有一段时间，会看到一些明显效果，其实整个体系的转变最困难的绝对不是技术，并不是说你技术能达到一个什么程度，如果技术不行，你可以学，再不行可以更换 。

最困难的是人的思想，人的整个思想转变太困难了。当然从上往下会通过一些上层，会简单一下，如果从下层想把一些人的思想转变，非常困难。

由这个引发出一些总结，整个SRE实施这块：

第一，一定是新人，能承担起SRE这个人一定是有开发背景的新人，不要找老人，老人思维模式是固化下来的，他不会做一些改变。

第二，企业文化，整个企业文化很多公司实际上是不成功的，很多公司实行SRE或者 DevOps 这些东西都是失败的，为什么失败？其中最重要的原因就是四个字企业文化，企业文化是否允许你做一些尝试，这个很关键。

第三，敏捷管理，这个有点老生常谈，运维人员，我们在座的都是搞运维的，其实是很封闭的。我们对开发这些年的发展有很多创新的思想，比如其中有一项就叫敏捷管理。这些东西对于我们运维能不能用得上，项目管理的机制，整个项目的配比、测试，再到研发、线上，这些东西有没有值得我们参考的。在我们那实际是把开发的那套经验应用到运维项目管理上，开发走项目制，敏捷管理的模式。

四、个人心得和感悟

4.1 我对运维体系的理解

最后讲一下个人的心得，首先谈谈我对运维体系的理解。

第一，所有的运维体系都是对人性的管理，你对人性是怎么看的？你认为人性是本善还是本恶的，如果我认为人性是恶的，那我接下来要做的是制定制度、流程、惩罚；如果我觉得人性是善的，那我会给他更多发挥的空间。但是人性随着时间推移会发生变化，这个对运维的管理者，尤其对运维的领导提出很多考验。

第二，运维体系越简单越好，目前体系有点复杂，这很正常，随着时间推移一定会统一起来，这个是我是持乐观看法。

第三，小心蝴蝶效应，我们做任何一些修改都会产生很严重的后果。

4.2 我们该如何选择 ITIL 还是 DEVOPSRE ？

ITIL 有一套很成熟的理论体系，最重要的一点是整个 ITIL 运维是可控的，你会发现无论是故障处理也好，发布管理也好，这些东西在整个 ITIL 体系中对外部门的要求是微乎其微的。如果一个初创公司在做这些事情是很容易见到效果的。

顺势而为，这四个字我体会是非常深的。所有事情是顺势而为，就会轻松很多，不要为了改变而改变，接下来就会对新的思想容纳，很多时候都是故障驱动，当发生故障之后，你会发现我处理问题会越来越简单。

END

近期好文：

第八届全球运维大会

即 GOPS2017·上海站将于2017年11月17日-18日在上海举行

各种精彩等您发掘。

点击阅读原文关注活动官网